A wide variety of computer software programs implement licensing restrictions to limit the number of instances of the program that may be executed by a user or computer. Licensing restrictions are most typically implemented to obtain licensing fees and revenue for additional software executions on more than one workstation. Many different licensing enforcement mechanisms exist in software applications, but these mechanisms generally fall within two distinct licensing models.
The first model is the nodelock concept, where the software is restricted to a specific machine for execution—which is generally determined at installation time. An additional restriction on a nodelock license may be how many instances of the program can be executed simultaneously. This often requires techniques that tie the license to some particular hardware or software configuration, thus preventing the software instance from being executed elsewhere. This model is typically limited to single-instance software applications that operate exclusively on only one computing system.
The second model is the floating (or network) concept, where a specific number of licenses are purchased, and the application contacts a license manager or other key server to determine if the user can obtain a license to execute it. Floating licenses are not entirely unrestricted, but they may be adapted to much larger processing environments. For example, floating licenses might be restricted by the total number of licenses available, userids that can execute the software, or IP Address ranges where the software is capable of running
In a massively parallel processing (MPP) environment (such as is embodied by many “supercomputer” systems), applications are generally submitted via a scheduler and may run on many CPUs. For example, the application may execute using a few CPUs while testing, then tens of CPUs on one run, hundreds of CPUs the next time, and thousands of CPUs the next time, depending on the particular job being executed. In large MPP installations, it is impractical (for obvious cost reasons) to use nodelock licensing, as each CPU in the MPP machine would have to be licensed, or applications would need to be restricted to a subset of CPUs where they could be executed. Based on the varying complexity of jobs, this is not a realistic restriction. Further, with a floating license model, there is the necessity that the application be able to contact the license server from each instance where it is running In the situation where there are multiple compute elements (cores or CPUs) on a node, all using the same IP address, a network/floating license would have to license each compute element on the node.
Many MPP configurations keep individual CPUs on a private network to avoid latency and bottlenecks that occur due to name serving and a shared LAN. Therefore, a license server may not even be able to execute on an MPP system—leaving many applications with nowhere to authenticate its use. Without the ability to authenticate a license, many software applications cannot execute.
Of course, possible workarounds to the multi-processor licensing problem include either eliminating the license restriction completely, or purchasing licenses to cover every possible CPU that might operate in the computing system. However, the up-front cost of purchasing rights to unlimited software would be orders of magnitude higher to offset the loss of per-CPU licenses. Further, many software vendors do not allow licenses to be customized or reduced in price on the basis that the computer is “more powerful” or the software runs in a multi-processor setting. Techniques are needed for effectively managing the use and distribution of software licenses in a large processing environment, such as a MPP supercomputer configuration.